So I don't forget it, since recent sudo package resets environment even for $HOME, the working sudoers (5) for me is:

Cmnd_Alias PBUILDER = /usr/sbin/pbuilder, /usr/sbin/cowbuilder
Defaults!PBUILDER env_keep+=HOME You may have to adjust the commands, YMMV.

For some reasons, I had to create some slides, and it's been some time I wanted to do some latex/beamer, so I jumped in and created them using vim (hating latex/beamer a few times in the process, but that's expected. At least, I didn't have to hate OpenOffice this time). Now, when presentation time comes, I started missing the nice Presenter Console extension for OpenOffice. It's a nice extension which (a bit like Keynote) (and maybe other) enables you to seperate the beamer and laptop screens. So you put on the beamer the presentation itself, and on the laptop one you can put you notes, the next slide preview, a nice countdown etc. Really useful, but it's only for OpenOffice (or PowerPoint) slides, not for pdf ones. So I started looking at PDF readers which could do that, and found multiple solutions:

• Cyril (Brulebois) proposed to start two pdf readers (one for each screen), to have them shifted by one slide, and to advance both of them at the same time (using xdotool for example). Not really convenient but, indeed, it /could/ work;
• in the same vein, some people proposed to use Impress!ve, which has the ability to run a script when changing slide. So again, one starts two pdf readers (Impress!ve and another one) and make Impress!ve change the preview reader each time it changes slide. Again, it should work, but it's not really convenient.

So in the end, I was almost ready to submit a bug report to epdfview (which I already maintain in Debian) asking for that new feature, when I found PDF Presenter Console which does exactly what I want. I'm not sure the project is really active at the moment, and I had some problems with the tool not detecting one of the screen (so it only appears on the beamer, or only on the laptop). It might be related to xfwm4 or something, I already contacted the developer about that. In the end, it's not 100% reliable (so I'm not yet packaging it for Debian) (especially since it uses CMAKE) but once it started, it does the job pretty fine. That's just something I wanted to share in case people would be interested.

Ok, so following the trend, I created some time ago a new GPG key, which I'm now transitioning too. I've set up a transition document, available at http://molly.corsac.net/~corsac/key-transition.txt. It's signed by both the old and the new keys and is reproduced below:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160,SHA512
Wed, 11 Nov 2009 13:44:05 +0100
I've recently set up a new RSA-based GPG key, and will be transitioning away
from my old DSA-based one.  The old key will be revoked soon, so I prefer all
future correspondence to use the new one.  I would also like to ensure that
this new key is well-integrated into the web of trust.  This message is signed
by both keys to certify the transition.
The old DSA key was:
pub   1024D/C5C05BAE 2004-11-11
      Key fingerprint = DE26 2FC4 7097 FFC6 DE2C  D8C0 4D44 C020 C5C0 5BAE
The new RSA key is:
pub   4096R/71EF0BA8 2009-05-06
      Key fingerprint = 4510 DCB5 7ED4 7040 60C6  6476 3055 0F78 71EF 0BA8
If you already know my old key, you can verify that the new key is
signed by the old one:
  gpg --check-sigs 71EF0BA8
If you don't already know my old key, or if you're extra-paranoid, you
can check the fingerprint against the one given above:
  gpg --fingerprint 71EF0BA8
If you have previously signed my old DSA key, and if you're satisfied
that you've got the correct new RSA key, then I'd appreciate it if you
would sign my new key as well:
  caff 71EF0BA8
The caff program is in the signing-party package in Debian.  Please be careful
to generate signatures that don't rely on the weakening SHA-1 hash algorithm,
which requires some careful configuration even if you've already configured
gpg correctly.  See http://www.gag.com/bdale/blog/posts/Strong_Keys.html for
the gory details.
Thanks,
- --
Yves-Alexis Perez
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREDAAYFAkr6sqQACgkQTUTAIMXAW64HiACeIyabQueDHAeiAX8EkIeApiDj
++UAn2z7YkjHx0lQh0+s5WdhikG0YztiiQIcBAEBCgAGBQJK+rKkAAoJEDBVD3hx
7wuodUcQAKMbG9Rehxz+uZ6fST99cHt5Fjnv9TorY4hQaQK+85ZgiwPaHMHfYM1G
5hcrXI+JFUpz8j40deZuaWuspOdHBHwnHNQril8MqT0CJgtB6HFTo+w/7Lmmui5M
DDMMed39UJl7bF73hV9ywGecxPpeh+dtoVnh0VT16uK2xTvW6ICEZgaPw1xfPUHS
+jxQ7I05X1OWQkPpmhxXJqGclDyO+qx4CJZsOxUAvt2LphHxhZxB3QE5OUdudGKQ
AH6KhC4rpNQdJVMX20SG8PybL/AipN3Y8N/63VkoqVC2heRlaQ69HjsuqIAkIyan
hHnqmJH8Q+TDTbdKZvOQv6jcd4o3VSibz0T9MwnOfqQ0uRYyTpaXC0vLUH6lXaC4
eK+VVWbY8vCAFHR3h80Q61i2me2HU5ly7a/W22dz19zzDNNC5q9MO78uIYkUK78N
Z0wzJrmOxRyhvs5DOSOpNVlXZhffNQM1f42xxG8cUDaIf7pR5jK+xqHV7tIBQE1D
CrD0mt+YQCnngK0i4wQTO7VT/vjypf4A9W+VSsoJJpRhBbngU4pHu9JWqO84/7AA
j5FN8ug15MWysaS+FQ/EqzHmT7BGBWaTPv3yGlHKUjx0w4bPEpbH7y3fwHAcmOFf
xFRzvZFQ03zeer06yAqTVNuwr77HZgrCzgyQVgIkegAg6iUPiZcs
=CBT+
-----END PGP SIGNATURE-----

Ok so there were some reactions to the Call for help post. I had three direct offers for help in pkg-xfce, not sure if other teams had such propositions. Some people asked me to correct various number for the active contributors . Basically, the numbers are what the feeling I got from people working in those team. Julien Cristau wants me to correct the number of debian-x active contributors to 0. (yes, zero, that means nobody, nadie, personne). Basically he doesn't have time anymore, and Brice Goglin can't really keep up. So, for those who care about shiny X effects, and stuff like that, you help would be gladly appreciated (and no, you don't have to own each and every chipset in the world to give some time). Aurelien Jarno wants me to add that at the moment there are 2 (two) active libc contributors, plus one on GNU/Hurd and one on kfreebsd. Frans Pop wants me to add that there are ~85 people working on d-i and that the problems the team might face aren't only related to the lack of manpower (and I don't really want to enter politics) Finally, it seems that some people (well, only one at the moment, but it's enough for to feel the need to precise) though the numbers previously given would dismiss contributions for the active contributors. That wasn't my intention, so I apologize if you are an active contributor in one of that team and thought I dismissed your contribution. If it wasn't clear enough, my point is to show that quite some teams are lacking manpower (some team miss other things too, like leadership, coordination or whatever) and users shouldn't be scared to contribute to them. Those are core teams, without them Debian wouldn't work at all (not to mention derivatives), so it's a good idea to join them. Now, what if you do want to help, but don't know how. On the previous post I gave links to teams website, wiki page or QA page. You should be able to find a mailing list or contact mail you should be able to write to. Just write that you want to offer some help, that you don't know how and where to start. Add what you're interested in, what you find fun, and your technical knowledge. Don't be shy, and you don't need to be a Debian Developer (nor even a Debian Maintainer) to contribute. Thanks!

So yesterday we had a really nice meeting with few french Debian folks. Luk and Ralf were visiting us, so we went at Prosper's for some meat and wine (and Aberlour). We were a bit too much to be able to speak to everybody (so mainly there were two 6-packs of people), but it was fine anyway. Though, the main point of the evening was that some (most?) teams in Debian are really (*really*) understaffed, and it might become problematic in the near future (like now). For example, from what I understood:

• debian-x has one active contributor
• pkg-xfce has one active contributor
• evolution has one de factor contributor
• pkg-gnome is better since Josselin had some help, but it's still not perfect
• d-i has only one active contributor
• libc has only one active contributor

I don't know the state of other teams, but it doesn't really look fine for the incoming freeze. So if you want to give some help, even if you're not yet technical enough, feel free to offer it to the teams above. Usually, starting with just using the package is enough. If you use it, you want it well-maintained, and there _are_ stuff to do to which don't require large technical knowledge, and the (few) active contributor will be happy to have some help and point you to what you can do. If you want to give some time to Debian, before filing some ITPs (even if you'd really like to have that package you use everyday), check if you can't do something for those above teams (and others which might need help too, like release team or kernel). Oh, and don't be scared, working on Debian is fun. It's time consuming, but it's rewarding. Don't let it become not fun.

Since we uploaded Xfce 4.6 into Debian Sid, last week, not much have happened to most people. We had some bug reports, but mostly from amd64 users, because i386 and ppc packages are not yet available. The aren't all built at the moment. You can follow the build status here if you want. Most packages are built now, but xfce4-settings is waiting for libcanberra which is not installable because of a transition and a package waiting in NEW. It's quite painful to have this upload a bit harmed by this, but there's not much we could do. We already passed NEW when uploading to experimental to minimize the delay where unstable would be unusable, but we can't do that for packages we don't maintain but depend on. I'm wondering if, for Xfce 4.6.1 (which is supposed to be out this weekend but won't because of some problems on the release manager box), I won't disable the sound settings in xfce4-settings and thus get rid of the libcanberra build-dep. If you have keyboard (layout and shortcuts) related bugs, make sure to re-assign the shortcuts correctly, and re-set the keyboard model and layout in the keyboard settings. There was a quite large xorg update at the same time, which now use hal and console-setup stuff. So you may have problems with that and it can be a bit hard to know what's going wrong (settings migrations from Xfce 4.4 to Xfce 4.6, bugs in Xfce 4.6, configuration problems, conflicts, bugs in xorg etc.) But all in all, for amd64 users, it seems the transition is well received and not that bugs have been reported yet (I'm expecting bug reports to come more when i386 users begin upgrading).

Following the ACCEPT on packages on NEW during my vacations and the ack from the release team, I've just uploaded all Xfce 4.6 packages to unstable. Packages for your architectures should arrive on your mirror along the weekend. the NEWS.Debian (which will be displayed if you use apt-listchanges (which is a good idea)) will warn you about some upgrade precautions to take. I'm reproducing it here:

xfce4 (4.6.0.1) unstable; urgency=low

Xfce 4.6 includes multiple changes which are not directly visible to the
user but might cause problems in rare cases.

Settings management have been moved from the old MCS Manager to the xfconf
system. User settings will be migrated automatically at first Xfce 4.6
startup using the /usr/lib/xfce4/xfconf-migration/xfconf-migration-4.6.pl
script contained in xfce4-utils. Once those settings have been migrated,
the automatic run will be disabled but the script will stay (for future
users).

Menus are now managed using a dedicated library, used by various Xfce
components (including xfdesktop4 and the menu panel plugin). This library
tries to support the freedesktop.org specifications, but is not totally
complete and thus lacks the support for some items, like .
This renders useless the menu editor previously shipped with Xfce 4.4.
Solutions for menu editing can be found at the following address:
http://wiki.xfce.org/howto/customize-menu

As the upgrade is pretty invasive, it is recommended to quit Xfce before
doing so, but it's not required and upgrades have been made from the
desktop environment without problems. In that case, be sure to quit Xfce
not long after the upgrade.

-- Yves-Alexis Perez <corsac@debian.org> Thu, 02 Apr 2009 21:19:53 +0200 The xfce4-goodies will be updated soon to match the new goodies present for Xfce 4.6, and the desktop task (the standard install when you choose desktop=xfce in the installer) will be updated too (there's an ongoing discussion on pkg-xfce mailing list to select which packages should be part of that install). Have a good upgrade!

As some people may have noticed (especially people in #debian-xfce and other Xfce fans), Xfce 4.6.0 has just been released. Packages are already prepared, since the packaging is done in parallel with the release cycle. I don't really plan to upload anything to my repository, now that Lenny is released and we can break unstable. That being said, I won't upload to unstable directly, as we have some packages which need to go through NEW. NEW is quite huge this days, so those packages won't leave it soon, and for consistency I'd prefer not breaking unstable completely, with a mix of 4.4 and 4.6. So first uploads targeted at experimental, and then when all packages are out of NEW, unstable. In the meantime, I already uploaded a new desktop-base version with config files useful for the new configuration system in 4.6. One of theses files will conflict with one in xfce4-session. Yeah, I shipped that file in xfce4-session when it was private, now it's time to go official. So yes, this morning you may have a conflict with desktop-base. It's not a problem in desktop-base (you don't need to report a bug). Just an inconsistency with an un-official, un-supported repository package, and an official package from main. Just force the overwrite or something like that. Or hold the upgrade until xfce4-session is available. As I already said, no special dependencies informations will be used in packages uploaded to Debian, so it may break your system at upgrade. The best solution would be to clean the packages from my repository before trying to upgrade to the ones in Debian (but it should not be too broken, in the end). For the record, besides the desktop-base / xfce4-session conflict, I didn't have any problem upgrading to the packages I should upload to experimental. More on this when things have settle down and we start uploading to unstable.

Hey hey, look what I had in my mailbox this morning: Just in time for Lenny release, here are my precious cookies for BugSprint. Thanks Franklin!

Hey, Xfce 4.6 Beta 2 Hopper has just been released and, guess what, packages are already available. Still not in unstable (or even experimental), that will wait post-lenny. You can install it from my repository, and, as usual, there's no Debian support on them. The known_issue page is currently quite empty, and this beta looks really quite polished. Packages currently available are i386 and amd64, powerpc will be available when I have time to put the mac at build. This beta features mostly bug fixing, and some features too:

• power management stuff in xfce4-session. Based on a patch included long ago in Ubuntu, it means that when you click the logout button it'll ask you if you want to suspend/hibernate the box. That works through hal and it may need some tuning on the machine. Reports appreciated here or there. 
• soname bump in xfconf. That means package renaming from libxconf-0-0 to libxfconf-0-2. No standard upgrade path (Replaces:) is provided because I don't want to clutter the packages before upload to Debian. This will continue for following changes (libxfconf-0-3 for rc for example). For the final release the library name will be changed to libxfconf-1 and the soname will be reset to 0, which means the package name will be libxfconf-1-0. There again, no upgrade path will be provided for people using my repository. The only upgraded path supported will be 4.4 →4.6. (but you won't be totally alone in the dark, I use 4.6 beta on my laptop so I'll pass through hell before you)
• keyboard shortcut can be configured (both window manager ones and applications) and there is now conflict handling
• session management has been greatly improved, you can now save the session immediately (a long-wanted feature) and it manages stuff like SMRestartImmediately etc.

The official announcement can be found there.
Have fnu!

The first Xfce beta for 4.6 (codenamed “Fuzzy”) has just been release. As usual, it's available in my private repository, for early testers. As usual, be warned, this is a beta, not supported by Debian in any way. Bugs can and should be reported to Xfce Bugzilla. The known issues wiki page has been updated, please look at it before any test, to see what's supported and what isn't, see the various problems you may encounter etc. Some stuff has changed since Pinkie  so some settings aren't valid anymore. Migration script from 4.4 has been updated,but not for alpha users. I cooked some script to migrate those settings from an alpha:

 #! /bin/sh

for prop in $(xfconf-query -c xfce4-keyboard-shortcuts -l grep -v provider grep -v command )
do
  value=$(xfconf-query -c xfce4-keyboard-shortcuts -p $prop tail -n1)
  newprop="/commands/custom$ prop "
  echo "prop=$ prop , newprop=$ newprop , value=$ value "
  xfconf-query -c xfce4-keyboard-shortcuts -n -p $ newprop -s "$ value " -t string
  xfconf-query -c xfce4-keyboard-shortcuts -r -p $ prop
done Enjoy!

Upstream just announced the release of Xfce 4.6 Alpha (codenamed “Pinkie”). I've already prepared some packages, which I won't upload to experimental yet, because the packaging is not yet ready for upload (mainly copyright stuff) and because it's alpha quality, and as we are in testing freeze period, and about (:) to release Lenny, I don't want to mess with that. So, in case you'd like to test them, they are available from my personal repository. As usual, be advised there won't be any official support for those packages. Don't report bugs on Debian BTS, and report software bugs on Xfce bugzilla. Feel free to pass on #debian-xfce on freenode if you need some help, but be prepared to front problems :) Basically there are some new packages:

• xfconf (configuration framework)
• xfce4-settings (xsettings and internal settings daemon)
• libxfce4menu (menu library)

Use apt-get dist-upgrade after updating your apt sources, It'll remove part of Xfce 4.4.2 (and especially xfce-mcs-manager, replaced by xfconf/xfce4-settings) and upgrade another part. Some packages may stay, like libxfce4mcs for example, which is still needed if you use notification-daemon-xfce. This one will be replaced by xfnotifyd at some point in the future (maybe for beta 1). It's advised to do the upgrade from outside of Xfce 4.4.2, just in case. Most settings will be migrated at first run. Look at the new announce for links to know issues, bug reports etc. Happy testing, and remember: don't do that on production boxes.

Even though I ve dealt with IPv6 for almost a decade, have delivered presentations, and given multi-day courses on IPv6 security aspects, I ve never actually added IPv6 to my own server/home network infrastructure because it seemed that Linux and/or Debian just weren t ready for it. This seems to have changed (although there are still a number of problems) and in less than a day, I put a few of my machines online. In the following, I d like to share with you how I did it.

Kernel versions and stateful connection tracking Unfortunately, I have to start off with some bad news: even though Debian etch, our current stable release, which uses a Linux kernel version 2.6.18, speaks IPv6, I cannot recommend it for deployment, as the 2.6.18 kernel does not support proper stateful connection tracking for IPv6, and thus makes it impossible to firewall hosts in a sensible manner (I always add local packet filters to all my hosts, and if only to guard against the situation when a user installs a malicious programme to listen on a high port). Of course, it is possible to configure a packet filter statelessly in an acceptable manner once you know the use case, so do with this information what you wish; I prefer to stay general for now. For me, a remedy is almost around the corner: the 2.6.24 kernel seems to support stateful connection tracking for IPv6, and it s even available for etch as it will be included in the upcoming etch-and-a-half release. I simply ended up using the kernel packages pre-release, and so far have not had a problem with it. To do so, add the following line to your /etc/apt/sources.list, making sure to use a close archive mirror:

deb http://ftp.xx.debian.org/debian etch-proposed-updates main

I then just upgraded the system and pulled in all proposed updates. As that may have let in software that won t be part of etch-and-a-half, or even lenny, you may want to pin the archive and only upgrade the kernel packages, by adding to /etc/apt/preferences (replacing amd64 with your architecture):

Package: *
Pin: release a=proposed-updates
Pin-Priority: -1
Package: linux-image-2.6.24-etchnhalf.1-amd64
Pin: release a=proposed-updates
Pin-Priority: 600

Alternatively, you could use the 2.6.24 linux kernel packages on backports.org.

Xen and IPv6 One drawback of switching to 2.6.24 is that you cannot run a dom0 on that machine any longer, so by practical extension, you cannot connect it to the IPv6 network with a packet filter in place. Supposedly, running 2.6.24 instances on a 2.6.18 dom0 is reported to work, however.

Configuring the packet filter The first thing I did was to configure the packet filter on each host appropriately. Unfortunately, this is harder than it should be, because to quote one of the netfilter developers when ip6tables was conceived, someone had a big bad brainfart : rather than adding IPv6 rules to your existing iptables ruleset, you have to create a new ruleset, duplicate all chains, networks, hosts, and individual rules, and maintain the two in parallel. Even though there are efforts of unification on the way, I speculate it ll take another couple of years until PF_INET6 will be fused into PF_INET and one will be able to do sensible cross-address-family packet filtering with Linux. Since I ve recently started to look (again) at pyroman, maybe the most logical way forward would be to extend it to write both, IPv4 and IPv6 rulesets from its knowledge about the hosts and networks you configured. Anyway, we want to get stuff working now! Thus, let s configure ourselves a packet filter. (Almost) all IPv6-related filtering must be configured via ip6tables (read on further down about IPv6 in IPv4 tunneling, the reason I said almost ). The following is a simple default ruleset to start with, which I put into /etc/network/ip6tables to load with ip6tables-restore:

*filter
:INPUT REJECT [0:0]
:FORWARD REJECT [0:0]
:OUTPUT ACCEPT [0:0]
:in-new - [0:0]
### INPUT chain
# allow all loopback traffic
-A INPUT -i lo -j ACCEPT
# RT0 processing is disabled since 2.6.20.9
#-A INPUT -m rt --rt-type 0 -j REJECT
# allow all ICMP traffic
-A INPUT -p icmpv6 -j ACCEPT
# packets belonging to an establish connection or related to one can pass
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# packets that are out-of-sequence are silently dropped
-A INPUT -m state --state INVALID -j DROP
# new connections unknown to the kernel are handled in a separate chain
-A INPUT -m state --state NEW -j in-new
# pass SYN packets for SSH
-A in-new -p tcp -m tcp --dport 22 --syn -j ACCEPT
# log everything else
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT6]: "
### OUTPUT chain
# RT0 processing is disabled since 2.6.20.9
#-A OUTPUT -m rt --rt-type 0 -j REJECT
# allow outgoing traffic, explicitly (despite chain policy)
-A OUTPUT -j ACCEPT
### FORWARD chain
# RT0 processing is disabled since 2.6.20.9
#-A FORWARD -m rt --rt-type 0 -j REJECT
# disallow forwarded traffic, explicitly (despite chain policy)
-A FORWARD -j REJECT
COMMIT

Note that this recipe is pretty much unusable on pre-2.6.20 kernels due to their broken implementation of stateful connection tracking. The ruleset should be fairly obvious, but you might wonder about my use of REJECT and allowing all ICMP after all, you ve heard for the past 30 years that ICMP is a bad hacker protocol , and Internet security is no domain for being nice to people, so to prevent any information disclosure, you should DROP connections, not let people know that they re simply not allowed. Well, to hell with all that! I don t see a single reason or attack vector that is foiled by DROP or disallowing ICMP. In fact, it s just security by obscurity, and might inconvenient at the same time. ICMP is also much more important with IPv6 than with IPv4 (it replaces ARP, for instance), and it s actually useful to be able to ping hosts, or get back informational messages on why something failed. Finally, rejecting traffic rather than dropping it doesn t suggest to a hacker that something s hidden here. Then there is RFC 4890, which almost made me puke. This document is part of the reason why I say: let s fix problems in the kernel, rather than shielding them with unreadable and unmanageable rulesets!

Getting connected If you already have an IPv6 address, you re basically ready to go, but may want to read further down on how to connect your local network to the IPv6 Internet as well. If you are searching for a provider, have a look at the list of providers with native IPv6 connectivity over at sixxs.net. If you are reading up to here, I assume you are connected to the Net with IPv4. There are two ways for you to move towards IPv6: 6to4 or by way of a tunnel provider. A Kiwi website explains how to setting up 6to4 connectivity, and thus I will concentrate only on the tunnel approach. Even though everyone can set up 6to4 in a breeze without any accounts or waiting, there are a number of security considerations, it s pretty ugly to debug (due in part to asymmetric routing), and makes your life unnecessarily difficult when all you have is a dynamic IP that changes from time to time. If you are stuck behind a NAT gateway, you cannot use 6to4 either. Thus, I prefer the tunnel approach. With the tunnel approach, IPv6 packets are wrapped up in IPv4 packets on your host, and sent to the IPv4 address of your tunnel provider, who has native IPv6 connectivity. The tunnel provider unwraps your packet and shoves the contained IPv6 packet onto the backbone. The IPv6 address you used as source address is routed to the tunnel provider, so any replies arrive at their machines, where they re again wrapped into IPv4 packets and sent to your (publicly-accessible) IPv4 address. Those IPv4 packets specify payload type 41 ( ipv6 ), which is why we need those -p ipv6 -j ACCEPT rules in the iptables ruleset. There are a few tunnel providers out there. I chose SixXS and have not regretted my choice. I shall thus assume that you do the same: sign up for an account right now, so that you have it by the time you finished reading this document! SixXS works on a credit system: tunnels and subnets cost credits, which you can accumulate by maintaining your tunnels properly. This ensures that everyone can play around, but to do more advanced stuff, you need to first display competence with the basic concepts. Your first step with SixXS will be to request a tunnel. SixXS offers three types of tunnels:

• static tunnels, for those with static IPs,
• heartbeat tunnels, for those with dynamic IPs, and
• AYIYA tunnels, for those behind NAT gateways.

Each of these tunnels have advantages and disadvantages, as everything does: the first two types of tunnels use IP protocol 41 packets to encapsulate the IPv6 packets. As such, there are security considerations involving the impersonation by spoofing, and all upstream firewalls must let protocol 41 pass. AYIYA addresses these problems by using signed packets, but that solution comes with extra computation overhead and smaller MTUs. I suggest to use the first type of tunnel that fits your situation. Debian s aiccu package can take care of heartbeat and AYIYA tunnels for you, and it can even set up static ones. During registration, you will also need to choose a PoP , which stands for Point of Presence . If your country only has a single PoP, that s the one you will end up using (unless you have a good reason for another one), but if there are more options, I strongly suggest that you go through the list of PoPs and select the one with the best roundtrip time and lowest latency from your location! Note that you must answer ping requests (ICMP echo-request) from the PoP you chose, or else the tunnel will not be created. Once your tunnel request gets approved, you ll get a /64 prefix, in which you only use two addresses: the PoP will configure the :1 address and you need to configure your host to use the :2 address on the tunnel interface. You ll also be told the IPv4 address of your PoP endpoint . Joey Hess taught me that aiccu can set up the interface for you, using the data it queries from the SixXS registration (TIC) server. I tried it, and it works. However, I prefer the pure ifupdown approach, as it makes things explicit and allows me to use the hooks for stuff like loading the packet filter. So in my /etc/network/interfaces, you can find:

auto sixxs
iface sixxs inet6 v4tunnel
  endpoint 194.1.163.40
  address 2001:41e0:ff00:3b::2
  netmask 64
  gateway 2001:41e0:ff00:3b::1
  ttl 64
  pre-up ip6tables-restore < /etc/network/ip6tables
  up ip link set mtu 1480 dev $IFACE
  up invoke-rc.d aiccu start
  down invoke-rc.d aiccu stop

Make sure to read about MTU values of the tunnel and adjust the 1480 value in the above to your tunnel settings and ISP connectivity. Also set ipv6_interface sixxs in /etc/aiccu.conf, if you are using aiccu, or else aiccu will bring up a duplicate/additional interface. If you tell it to use the same interface, it will actually execute all the same commands (which will fail), but won t report any errors. A future version will have a switch to prevent it from configuring the interface. Unfortunately, this will probably not work. The reason is that your regular IP packet filter (iptables, without the 6) doesn t let those encapsulating IPv4 packets pass, unless we tell it to; we probably want to do this early on in the chain, and also limit it to our tunnel peer, so:

iptables -I INPUT -p ipv6 -s 194.1.163.40/32 -j ACCEPT

For AYIYA, you need to open port 5072, either for UDP, TCP, or SCTP, depending on how you configured it. Also have a look at this FAQ entry on what a firewall needs to pass. If it still doesn t work, you have an upstream packet filter that needs some of those holes poked. Good luck. In most situations, the FORWARD chain does not get such a rule, since the tunnel terminates at the gateway, which routes to a native IPv6 network, or another tunnel. Allowing tunnels through a gateway is almost always a bad thing, as it would allow undetected and untraceable traffic from compromised boxes in the local network. The OUTPUT chain also does not need such a rule, if you have configured stateful filtering properly. Now bring up the interface and verify the connection:

# ifup sixxs
# ping6 -nc1 2001:41e0:ff00:3b::1
PING 2001:41e0:ff00:3b::1(2001:41e0:ff00:3b::1) 56 data bytes
64 bytes from 2001:41e0:ff00:3b::1: icmp_seq=1 ttl=64 time=74.0 ms
[...]
# ping6 -nc1 ipv6.aerasec.de
PING ipv6.aerasec.de(2001:a60:9002:1::184:1) 56 data bytes
64 bytes from 2001:a60:9002:1::184:1: icmp_seq=1 ttl=55 time=91.5 ms
[...]

Welcome to the Internet of the future!

Setting up an IPv6-capable gateway Your IPv6 connection works, but it s limited to a single address, and you do not get to specify the reverse DNS PTR record for it. Since the concept of NAT is mostly absent from IPv6 (thanks! thanks! thanks!), you will not be able to connect any other hosts to the IPv6 network. If your local network has a few hosts behind a gateway, you will need to request a subnet from SixXS and configure your gateway (which has the tunnel connection) appropriately. Don t worry, this is not really very difficult. First, request a subnet for your tunnel from your PoP via your SixXS homepage. Once approved, you will get a /48 prefix for your own use: 2^80 1.2 heptillion addresses which are yours to assign to every dust particle in your office or home, if you so desire. The way I set it up is to add the first of these addresses to your internal interface on the gateway, by adding the following two lines to the interface s stanza in /etc/network/interfaces; you will need the iproute package installed (which you should be using for everything network-related anyway):

up ip -6 addr add 2001:41e0:ff12::1/64 dev $IFACE
down ip -6 addr del 2001:41e0:ff12::1/64 dev $IFACE

Instead of bringing the interface down and up, just run ip -6 addr add 2001:41e0:ff12::1/64 dev eth0. Note the use of the /64 prefix instead of the /48 that got assigned, leaving only 20 pentillion addresses. Oh no! The reason for this is buried in the specs: basically, /48 is a site prefix, but individual networks should not be larger than /64, which is the prefix length of links in the IPv6 domain. Now is also a good time to enable IPv6 forwarding, e.g. like so:

# echo net.ipv6.conf.all.forwarding = 1 >> /etc/sysctl.conf
# sysctl -p /etc/sysctl.conf

Obviously, you will also need to change the policy on the ip6tables FORWARD chain. For now, let s just set it to accept. You should later create a proper ruleset, though!

# ip6tables -I FORWARD -j ACCEPT

Bringing IPv6 to your local network The final step is to spread the love to your local network. Refrain from selecting addresses from your subnet and assigning them to the local hosts, or wondering how to configure the DHCP server, because IPv6 does it differently: your gateway will advertise its routes (which includes a default route) to your network, and each host will pick an address based on its MAC address (unless it already has an EUI-64 address assigned. This all happens automagically, at least with current Debian and Windows machines. On the gateway, you need to install radvd and simply tell it which prefix to use on which interface. My /etc/radvd looks like this, and I won t explain it:

interface eth0
 
  AdvSendAdvert on;
  prefix 2001:41e0:ff12::/64
   
   ;
 ;

Note again how we advertise a /64 network rather than the /48 we own . You cannot advertise smaller networks if you want automatic configuration to work, and you should not use networks larger than /64 in any case. If 2^64 addresses are not enough for you, I trust you ll be able to figure out how to advertise another of your 65536 /64 prefixes in the /48 subnet to appropriate hosts. Restart radvd and run over to another host to witness how it automagically gets connected to the IPv6 network by scanning /var/log/kern.log and watching the output of ip -6 addr and ip -6 route. Try ping6ing from there! Find the dancing turtle! It should all work. If you don t like the automagic aspect of this, look into stateful configuration, using DHCPv6, as provided by dibbler-server and ?wide-dhcpv6-server.

Resolving names Take note of the IPv6 address of each host. There s a way to determine it given the host s MAC address, but this is easier (ipv6calc is also useful). You might want to let your local DNS server know by adding AAAA records in parallel to the existing A records, and possibly even adding PTR entries. If you re serious about IPv6, you can tell SixXS to delegate reverse lookups for the IPv6 addresses to your DNS servers, but you ought to refrain from polluting the DNS namespace. Note that bind9-host provides an improved host tool, which fetches all kinds of information about names, not just the one single information configured as default:

% host pulse.madduck.net
pulse.madduck.net has address 130.60.75.74
pulse.madduck.net has IPv6 address 2001:41e0:ff1a::1
pulse.madduck.net mail is handled by 99 b.mx.madduck.net.
pulse.madduck.net mail is handled by 10 a.mx.madduck.net.
% host 2001:41e0:ff1a::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.f.f.0.e.1.4.1.0.0.2.ip6.arpa
domain name pointer pulse.madduck.net.

Oh, and if you re really that curious about how IPv6 addresses are computed from MAC addresses, read RFC 2464. Basically, given a prefix 2001:41e0:ff1a:: and a MAC address aa:bb:cc:dd:ee:ff, the resulting IPv6 address is obtained by:

1. inserting ff:fe into the middle of the MAC address to yield aa:bb:cc:ff:fe:dd:ee:ff;
2. flipping the second lowest bit of the first octet to yield a8:bb:cc:ff:fe:dd:ee:ff;
3. removing the odd colons to yield a8bb:ccff:fedd:eeff, the EUI-64;
4. concatenating the prefix and this result to get 2001:41e0:ff1a::a8bb:ccff:fedd:eeff.

If you find your (Windows) IPv6 addresses changing all the time, you might be faced by privacy features .

Remaining issues Even though my IPv6 connectivity works, I have two remaining issues.

Sending larger amounts of data to the network I am experiencing a curious issue where outgoing ssh IPv6 connections time out and outgoing data transfers hiccup. I have yet to find out what s going on.

Mapping names to laptops Laptops generally have two interfaces, one with a cable, and the other wireless. Both of these interfaces will have separate MAC addresses, and by extension, the laptop will have different IPv6 addresses depending on how it is connected to the local network. I want to be able to connect to laptops without knowing the medium they use to connect to the network. Unfortunately, there seems to be no feasible way. The solutions I see are:

• override the MAC address of one interface with that of the other, which is going to cause bgi problems in the case when the laptop (accidentally) gets connected to the same network twice;
• add both IPv6 addresses as AAAA records to the laptop s DNS name, which will cause random delays when connecting as the resolver may return the currently inactive address first;
• set up mobile IPv6, e.g. by following this Mobile IPv6 how-to, which would allow accessing the laptop uniformly, no matter where in the world it is. Unfortunately, Debian s support for Mobile IPv6 is severly lacking at time of writing. Also, Yves-Alexis Perez notes that this how-to is horribly outdated and promised to tend to it Real Soon Now .

The second solution works for me for now, but I am interested in the third. In response to this document, Andreas Henriksson has suggested the replace the stateless configuration (radvd) with stateful configuration, using DHCPv6. I have yet to investigate this option. Jeroen Massar suggests to unite cable and wireless into a bridged interface, which seems like a very good idea.

Credits Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar, and everyone on #ipv6/irc.freenode.org for their help over the past few weeks, and all those who fed back comments in response to this document!

(this is an english repost from the original french one, for planet debian) Ok, this is just a procedure, which worked for me, for french taxes declaration. The french governement only allows on Linux configurations with i386 architectures, and firefox. This solutions works (at the date of the post) on a Debian Sid amd64, but should work on every x86/amd64 Debian, because we use a clean i386 chroot. Let's go:

# get the packages
corsac@hidalgo: sudo aptitude -R install cdebootstrap chroot

# create the i386 chroot:
corsac@hidalgo: sudo cdebootstrap -a i386 sid chroot http://ftp.fr.debian.org/debian

# bind-mount /tmp for Xorg in the chroot:
corsac@hidalgo: sudo mount -o bind /tmp debian/chroot/tmp

# Entering chroot:
corsac@hidalgo: sudo chroot debian/chroot /bin/bash

# configure apt:
root: echo "deb http://ftp.fr.debian.org/debian/ sid main contrib non-free" > /etc/apt/sources.list
root: aptitude update

# installing packages:
root: aptitude -R install iceweasel sun-java5-plugin

# no need to run iceweasel as root:
root: adduser corsac

# done for inside the chroot We now need two things in the chroot:

• the pkcs12 certificate, delivered by the DGI. If you don't have one yet, you'll be given one when declaring.
• .Xauthority, so we have some displays in the chroot

 corsac@hidalgo: cp ~/.Xauthority debian/chroot/home/corsac/ Time to re-enter the chroot:

corsac@hidalgo: sudo chroot debian/chroot /bin/bash

root: su - corsac

# we export the DISPLAY to use host X
corsac: export DISPLAY=:0.0

# ready to go
corsac: iceweasel Now you should be able to go to the website and declare. No need for symbolic link or LD_LIBRARY_PATH hack. I failed to use sun-java6-plugin. Don't hesitate to purge your chroot and restart from a clean one. You can also clean the folder where the shared lib is stored, in ~/.TaoUSign. Hope that helps.

Using Xfce on your laptop running Debian? The battery plugin is unusable? Don't panic, we're aware of this. Basically, the situation is a mess, for some reasons:

• upstream plugin only supports reading in /proc/acpi and /proc/apm
• /proc/acpi now only exists if CONFIG_ACPI_PROCFS_POWER=y in the current kernel config
• CONFIG_ACPI_PROCFS_POWER is deprecated and may be dropped in 2.6.26
• there's no warranty CONFIG_ACPI_PROCFS_POWER will be set for kernel shipped in Lenny

There is an open bug in Debian and in Xfce where we track the situation. Somebody proposed on the Xfce bug a patch to enable sysfs support on the battery plugin, and we integrated this patch on Debian (starting 0.5.0-3), but the patch is not really good, as it hardcodes too many things, and especially the directory names (it uses AC and BAT* while some people are know to have ACAD). So with the sysfs patch included, the plugin doesn't work at all on some users's config. The next plan is to remove this sysfs patch and revert to procfs, until we know better how everything will be in Lenny. In the meantime, Nick Schermer is hacking on a hal based branch of the battery plugin. I'm currently running it daily, and it works fine. Nearly all the low-level work is let to hal, and the battery plugin only takes care of the display, in Xfce panel. This is nice, but add a dependency on hald for the battery plugin, wich is something some user may not want. At first, I thought it would be better to release Lenny with 0.5.0 battery plugin and only after switch to the hal based one, and add the hald dep, especially since the plugin is still kind of experimental. But seeing the mess it is currently, we may have to switch before, and sooner than we thought. [EDIT]: xfce4-battery-plugin_0.5.0-6 was just ACCEPTED. It contains a fixed sysfs patch which fixes the “hardcode” problem. Thanks to Daniel Gibson!

In the end, I just bought a Brother HL-5250DN. Yeah I know, it wasn't in the list, but in the end, the lexmark one (which had postcript+duplex) wasn't available at a nice price, but I thought duplex printing was still a good idea. So I had to decide between a Samsung and a Brother. The Samsung had official Postscript while the Brother supported IPv6. I ended choosing the Brother one, and it's a good idea. The printer indeed support IPv6, but postscript too. Choosing “Postscript generic driver” in cups works pretty fine. IPv6 works too, but I faced two (linked) problems:

• mDNS seems to publish the printer through hostname.local/ipv4 and not hostname.local/ipv6
• cups uses only the IP part of the published address, so it uses the IPv4 and not the hostname (which resolves through IPv6 because I've setup mdns6 before mdns4 in /etc/nsswitch.conf)

Another problem in cup is that it doesn't support IPv6-only mDNS. With use-ipv4=no in /etc/avahi/avahi-daemon.conf, no printer can be found. This is #474464, waiting for the maintainer to comment. At least, it works fine on Linux. Now I'll make some tests on OS X and maybe windows.

I'm currently looking for a printer. I want a Laser printer, black & white should be enough, but color may be ok too if not too expensive (especially toner). I guess I prefer a network one, even if I don't really understand the way everything should work. As I understand it, a network printer just listens on a defined port (9100/jetdirect or ipp/63), and prints jobs sent by a spooler. There is no integrated spooler, so there are two solutions:

• install a cupsd on every box where I need to print (which is OK but a bit sub-optimal, imho, but I may be wrong)
• install a cupsd on only one box, wich will be the print server, and uses its address in /etc/cups/client.conf on every box I need to print on. This is ok, but on a home network there's no real need for a network printer in that case.

Maybe I shouldn't buy a network printer and just pick a usb one (especially since the FreeboxHD can serve as a laser printer if one plugs a usb printer on it. It listens on 9100/jetdirect so one can configure cups to pick it). I've currently narrowed my choices to:

• Samsung ML-2571n
• Lexmark e250dn wich is bigger but does duplex

Moe on #xfce avised me to pick a printer a bit more expensive, because it would be safer on a long term, and advised:

• Kyocera FS-1100n
  
• Brother HL-2150N

I don't really know what to do so, dear lazyweb, I'm asking you. What should I pick? This is for a home installation where we don't really print that often, so I don't want to spend too much, but where goodies like network and duplex printing are cool to have. Cups support is mandatory (except if there's another way to print easily, especially from gtk apps)

Hey everybody! Etch users will be pleased that they know have access to Xfce 4.4.2 backports in their favorite distribution. This release seems to fix the well known memory leaks in xfdesktop and xfce4-menu-plugin, so if you run Debian Etch on your desktop and are annoyed by them, you can try the backports. Everything is explained at backports.org website.

Yzah! At last, I am now an official Debian Developer. My account was created this night by James Troup, so now the waiting is over. 2+ years, pfiou. Now let's get back to work! Thanks everyone.